Apparatus and method for handover between heterogeneous systems

ABSTRACT

An apparatus and method for enhanced heterogeneous network handover using a media independent handover scheme is provided. A heterogeneous network handover method of the present invention includes generating, at a mobile node, self-location information, transmitting the self-location information to a management server which manages heterogeneous networks, searching, at the management server, surrounding networks using the self-location information, composing a set of candidate networks including at least one of the surrounding networks, transmitting information on the set of candidate networks to mobile node and deciding, at the mobile node, a target handover network among the candidate networks. Accordingly, latency during handover in a heterogeneous network can be reduced.

PRIORITY

This application claims the benefit under 35 U.S.C. § 119(a) of a Koreanpatent application filed in the Korean Intellectual Property Office onAug. 16, 2007 and assigned Serial No. 2007-0082362, the entiredisclosure of which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to an apparatus and method for handoverbetween heterogeneous networks. More particularly, the present inventionrelates to an apparatus and method that provide enhanced heterogeneousnetwork handover using a media independent handover scheme.

2. Description of the Related Art

Handover, or handoff, is a technical procedure for switching a call inprogress from the radio coverage area of one base station to anotherbase station while ensuring the continuity of the established call.

Handover is commonly performed when user equipment, currently in anactive communication session, moves between the cells of a homogenoussystem. With the deployment of various heterogeneous system networks,advanced handover techniques for supporting handover betweenheterogeneous networks have been developed. Handover betweenheterogeneous networks (also known as vertical handover) means aninter-technology handover such as a switch between a WiBro network andanother standard system network, such as a 2nd generation (2G) network,a 3rd generation (3G) network, or a wireless local area network (WLAN)based on the Institute of Electrical and Electronics Engineers 802.11(IEEE 802.11) standards.

Media Independent Handover (MIH) is a standard being developed as partof the IEEE 802.21 standard to enable handover in a heterogeneousnetwork environment. MIH is a seamless intermediate handover techniqueguaranteeing quality of service (QoS) between heterogeneous networksregardless of media types. MIH provides Event Services, Command Servicesand Information Services for allowing a mobile node having multipleradio interfaces to switch the communication session in progress to anoptimal network regardless of media type without requiring userinterface. With such services, the upper layers can perform a handoverto an optimal network.

FIG. 1 illustrates message flows in a conventional inter-system handoverprocedure. In FIG. 1, a mobile node (MN) 100 is attempting a handoverfrom a WLAN to a wireless metropolitan area network (WMAN).

Referring to FIG. 1, a mobile node (MN) 100 is serviced by a WLAN 101 asa serving network in step S110. If a link status changes, the MN 100transmits an MIH get information request message(MIH_Get_Information.request) to neighbor networks via an MIHInformation Service (MIIS) server 102 in step S115. The change of linkstatus is determined by comparing a link parameter value with athreshold value. If the link parameter value is greater than thethreshold value, it is determined that a change of link status hasoccurred. The high link parameter value indicates that the receivedsignal strength is weak. Accordingly, the MN 100 determines informationabout neighboring networks, such as received signal strengths of thedifferent networks, and prepares to perform a handover to theneighboring network having an optimal state. TheMIH_Get_Information.request message is formatted as follows and theparameters of the MIH_Get_Information.request message are defined as intable 1.

MIH_Get_Information.request (              InfoQueryType,             InfoQueryParameters              )

TABLE 1 Valid Name Type Range Description InfoQueryType An integer valuecorresponding N/A The type of query that is specified to one of thefollowing types: 1: TLV 2: RDF_DATA 3: RDF_SCHEMA_URL 4: RDF_SCHEMAInfoQueryParameters Query type specific parameters N/A Query typespecific parameters which indicate the type of information the clientmay be interested in.

The MIH_Get_Information.request is transmitted by MN 100 to requestinformation related to a specific interface, attributes to the networkinterface as well as entire network capability.

As shown in table 1, integer values of the InfoQueryType parameter ofthe MIH_Get_Information.request respectively correspond to TLV,RDF_DATA, RDF_SCHEMA_URL, and RDF_SCHEMA.

When the InfoQueryType is specified as TLV, the InfoQueryParameters is abinary string. When the InfoQueryType is specified as RDF_DATA, theInfoQueryParameters is a string which contains a SPARQL (Protocol andRDF Query language) query where the SPARQL query is supposed to containan appropriate query for obtaining expected RDF/XML data. When theInfoQueryType is specified as RDF_SCHEMA_URL, the InfoQueryParameters isa null string. Finally, when InfoQueryType is specified as RDF_SCHEMA,the InfoQueryParameters carries either the URL of the extended schemathe query originator wants to obtain or a null string when the URL ofthe extended schema is unknown.

In response to the MIH_Get_Information.request message, the MIIS server102 transmits an MIH get information response message(MIH_Get_Information.response) to the MN 100 in step S117. TheMIH_Get_Information.response message includes information on thecandidate networks that are selected by the MIIS server 102 inconsideration of the location of the MN 100. Upon receiving theMIH_Get_Information.response message, the MN 100 determines link reliefinformation in step S120. That is, the link layer of the MN 100 notifiesthat the current link established by MIH is released within apredetermined time. Accordingly, the MN 100 determines another link toperform handover to a new cell, i.e. a new network.

Next, the MN 100 receives information required for a new connection fromWMANs 103 and 104 as the candidate networks in steps S125 and S126. Forsimplifying the explanation, it is assumed that two WiBro networks basedon the IEEE 802.16 standard are selected as the candidate networks inFIG. 1. However, the number of the candidate networks can be changed andother the types of networks, such as cellular networks and WLANs, can beutilized.

Since the candidate networks 103 and 104 are WiBro networks, theconnection information includes Downlink MAP (DL MAP), Uplink MAP (ULMAP), Downlink Channel Descript (DCD), and Uplink Channel Descript(UCD).

If the network connection information is collected, the MN 100 performsa link scanning on the links of the candidate networks 103 and 104 instep S130 and then transmits a candidate query request message(Candidate_Query. request) including the information on the candidatenetworks 103 and 104 to the serving network 101 in step S132. TheCandidate_Query.request includes a link type identifier, networkidentifiers of the candidate networks, and information about operationsrequired for the current link after handover. Upon receiving theCandidate_Query.request message, the serving network 101 transmits ahandover (HO) query resource request message (Query_Resource.request) tothe candidate networks 103 and 104 in steps S135 and S136. The candidatenetworks are selected in consideration of the location of the MN 100,and the number and types of candidate networks are not limited to theexample of FIG. 1. In a case where five candidate networks are reportedby the MIIS server 102, the serving network 101 requests the radioresource information for handover to the five candidate networks.

In response to the Query_Resource.request, the respective candidatenetworks 103 and 104 transmit a query resource response message(Query_Resource.response) containing information on their resources tothe service network 101 in steps S137 and S138. Particularly, thehandover resource information response message may include handoveracceptability for the MN 100. The serving network 101 determines one ofthe candidate networks as an optimal network for handover inconsideration of the handover acceptability and resource status of thecandidate networks 103 and 104. Next, the serving network 101 transmitsa Candidate_Query.response containing information on the HO targetnetwork to the MN 100 in step S140.

Assuming that the candidate network 103 is selected as the handovertarget network, the MN 100 performs operations for establishing aconnection to the target network 103. Since the handover target network103 is a WiBro network, the MN 100 performs a ranging process forestablishing a connection link in step S145. After completing theranging process, the MN 100 determines successful handover completion instep S147 and is served by the new serving network 103 in step S150.Here, the communication link to the old service network 101 is released.In this manner, the vertical handover between heterogeneous networks isperformed.

As described above, in the vertical handover specified by the IEEE802.21 standard, the MN transmits MIH_Get_Information.request to theMIIS server whenever a handover to a new cell is required, and the MIISserver collects information on the networks in a core network anddetermines the existence of available heterogeneous networks forhandover. The MIIS server transmits the network status information tothe MN using the MIH_Get_Information.response message.

In the conventional standard specification, when a handover is requireddue to the movement of the MN, the core network predicts a location ofthe MN using a prediction algorithm and informs the MN of whether ahandover to a heterogeneous network is available. In the heterogeneousnetwork environment, however, the network resource management for thevertical handover is very complicated and inefficient real time handovertraffic may cause significant network problems. Such problems increaselatency and deteriorate communication reliability. That is, theconventional vertical handover method is limited in efficient handoverperformance due to the latency and communication reliability caused byinaccurate user location and mobility estimated by the core network.

SUMMARY OF THE INVENTION

An aspect of the present invention is to address at least theabove-mentioned problems and/or disadvantages and to provide at leastthe advantages described below. Accordingly, an aspect of the presentinvention is to provide a handover method and system in a heterogeneousnetwork environment.

Another aspect of the present invention is to provide a mediaindependent handover method and system that are capable of improvinghandover efficiency in a heterogeneous network environment.

In accordance with an aspect of the present invention, a handover methodin a heterogeneous network environment is provided. The method includesgenerating, at a mobile node, self-location information, transmittingthe self-location information to a management server which managesheterogeneous networks, searching, at the management server, surroundingnetworks using the self-location information, composing a set ofcandidate networks including at least one of the surrounding networks,transmitting information on the set of candidate networks to mobile nodeand deciding, at the mobile node, a target handover network among thecandidate networks.

In accordance with another aspect of the present invention, aheterogeneous network handover method is provided. The method includesgenerating, by a mobile node having multiple standard interfaces,self-location information and self-travel route prediction information,transmitting the self-location information and self-travel routeprediction information to a management server which managesheterogeneous networks, searching, at the management server, surroundingnetworks using the self-location information and self-travel routeprediction information, selecting handover candidate networks from amongthe surrounding networks searched along a travel route extracted fromthe self-travel route prediction information, transmitting informationon the candidate networks to the mobile node and performing, at themobile node, a handover to one of the candidate networks.

In accordance with yet another aspect of the present invention, aheterogeneous network handover system is provided. The system includesat least one mobile node for communicating with multiple heterogeneousnetworks, for generating self-location information, for transmitting theself-location information to a core network, and for performing ahandover on the basis of candidate network information received from thenetwork and a management server for managing the heterogeneous networks,for searching surrounding networks using the self-location informationreceived from the mobile node, for selecting at least one of surroundingnetworks as a set of handover candidate networks, and for transmittinginformation on the candidate networks to the mobile node.

In accordance with still another aspect of the present invention, aheterogeneous network handover apparatus is provided. The apparatusincludes a plurality of radio interfaces for communication withheterogeneous networks, a self-location information generator forgenerating self-location information and self-travel route predictioninformation and a media independent handover function for transmitting asurrounding network information request message containing theself-location information and self-travel route prediction informationto a heterogeneous network management server and receiving a replymessage in response to the surrounding network information requestmessage.

Other aspects, advantages, and salient features of the invention willbecome apparent to those skilled in the art from the following detaileddescription, which, taken in conjunction with the annexed drawings,discloses exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features and advantages of certainexemplary embodiments of the present invention will be more apparentfrom the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 is a flowchart illustrating message flows in a conventionalinter-system handover procedure;

FIG. 2 is a schematic diagram illustrating MIH system architectureaccording to an exemplary embodiment of the present invention;

FIG. 3 is a block diagram illustrating an MN having multiple radiointerfaces for supporting MIH between heterogeneous networks accordingto an exemplary embodiment of the present invention; and

FIGS. 4A and 4B are a message flow diagram illustrating a handovermethod in a heterogeneous network environment according to an exemplaryembodiment of the present invention.

Throughout the drawings, it should be noted that like reference numbersare used to depict the same or similar elements, features andstructures.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The following description with reference to the accompanying drawings isprovided to assist in a comprehensive understanding of exemplaryembodiments of the invention as defined by the claims and theirequivalents. It includes various specific details to assist in thatunderstanding but these are to be regarded as merely exemplary.Accordingly, those of ordinary skill in the art will recognize thatvarious changes and modifications of the embodiments described hereincan be made without departing from the scope and spirit of theinvention. Also, descriptions of well-known functions and constructionsare omitted for clarity and conciseness.

FIG. 2 is a schematic diagram illustrating MIH system architectureaccording to an exemplary embodiment of the present invention. In FIG.2, the system architecture includes an IEEE 802.11 WLAN and an IEEE802.16 WMAN. However, the handover system and method of the presentinvention are not limited thereto. For example, the handover system andmethod of the present invention can be applied to an MIH systemarchitecture in which other types of WLANs and WMANs and cellularnetworks coexist.

Referring to FIG. 2, an MN 200 is connected to the Internet via anaccess point (AP) 210 of the WLAN and an access router (AR) 230 of anInternet Protocol (IP) access network. The AR 230 is responsible for IProuting of packets from the MN 200 and acts as a Foreign Agent (FA). TheAP 210 communicates with the MN 200 over the WLAN access protocol andacts as a bridge between the WLAN and a wired network.

As illustrated in FIG. 2, the WLAN coverage area is overlapped with theWMAN coverage area and the MN 200 moves out of the radio coverage of theAP 210 so as to enter the WMAN area. The WMAN area is defined by theradio coverage of a Radio Access Station (RAS) 240 which provides accessservice to the MN 200 and manages radio resource. The RAS 240 alsoprovides authentication and security functions. An Access Control Router(ACR) 250 is connected to the IP access network. The ACR is responsiblefor IP routing and mobility management and performs IP multicast,billing, and mobility control functions.

A MIIS 260 is placed on a core network and is responsible for managingnetwork resources for supporting handover between the heterogeneousnetworks. In an exemplary embodiment of the present invention, the MIIScollects the information on the heterogeneous networks connected to theIP access network and provides the network information to the MN 200 inresponse to a network information request message. Although not shown inFIG. 2, an Authentication, Authorization, and Accounting (AAA) functionis further included in the architecture for performing packetencapsulation as a router of a home network and for authenticating aHome Agent (HA) which performs data tunneling to a currently registeredaddress of the MN and the MN's access.

In an exemplary embodiment, the MN 200, AP 210 of the WLAN, and RAS 240of the WMAN are provided with MIH functions so as to provide MIHservices.

FIG. 3 is a block diagram illustrating an MN having multiple radiointerfaces for supporting MIH between heterogeneous networks accordingto an exemplary embodiment of the present invention. Such MIH functionsare supported by other network elements. Although the network elementsof the respective networks, equivalent to the base stations, aredescribed with the MIH functions in this example, the present inventionis not limited thereto.

Referring to FIG. 3, the MN 200 includes a wireless interface unit 310which is capable of supporting multiple radio interfaces, an MIHfunction unit 320, and an MIH user unit (or upper layer unit) 330. Thewireless interface unit 310 is provided with the Physical layer (PHY)and Media Access Control (MAC) layer. In this example, the wirelessinterface unit 310 is provided with an IEEE 802.11 interface 312 forsupporting connection to an IEEE 802.11 WLAN, an IEEE 802.16 interface314 for supporting connection to an IEEE 802.16 WMAN, and a cellularinterface 316 for supporting connection to a cellular network. Ofcourse, other types of radio interfaces can be included in the wirelessinterface unit 310 in addition to the IEEE 802.11 interface, IEEE 802.16interface, and cellular interface.

The MIH function unit 320 provides services to the upper layer unit 330through a single technology-independent interface and obtains servicesfrom the wireless interface unit 310 through a variety oftechnology-independent interfaces. The MIH function unit 320 includes anevent service module 322, a command service module 324, and aninformation service module 326.

The event service module 322 provides event classification, eventfiltering and event reporting corresponding to dynamic changes in linkcharacteristics, link status, and link quality. The event service module322 also exchanges the event information with the base stations. Here,the base stations may include the AP of a WLAN, an RAS of a WiBronetwork, a Node B of a Wideband Code Division Multiple Access (WCDMA)network and a Base Transceiver Station (BTS) of a Code division MultipleAccess 2000 (CDMA2000) network. The command service module 324 providesthe command service which enables MIH users to manage and control linkbehavior relevant to handovers and mobility. The information servicemodule 326 provides details on the characteristics and services providedby the serving and surrounding networks. The information enableseffective system access and effective handover decisions. In anexemplary implementation as illustrated in FIG. 3, the informationservice module 326 of the MN 200 provides information on the currentlocation and predicted route of the MN. This information is contained inthe network information request message. Accordingly, the MN can quicklyreceive the information of the surrounding networks and perform handoveraccurately on the basis of the received information.

The upper layer unit 330 makes use of the services provided by the MIHfunction unit 320. The upper layer unit 330 enables an upper layerapplication to be seamlessly serviced especially in handover byassistance of the MIH function unit 320.

FIGS. 4A and 4B are a message flow diagram illustrating a handovermethod in a heterogeneous network environment according to an exemplaryembodiment of the present invention. In the illustrated example, thehandover method is described with a situation in which the MN 200switches the current WLAN link to a WMAN link. Of course, this is forexample only an in no way limits the application of the presentinvention.

Referring to FIGS. 4A and 4B, an MN 200 is served by a serving network(WLAN) 401 in step S410. If a state of the link connected to the WLAN401 deteriorates, the MN 200 requests an MIIS 402 for information aboutsurrounding networks. In more detail, the wireless interface unit 310 ofFIG. 3 detects the change of the link status of the 802.11 interface 312and reports the link status change to the MIH function unit 320. Thelink status change is detected by comparing a link parameter value tothreshold value. If the link parameter value exceeds the thresholdvalue, the wireless interface unit 310 determines that the link state ischanged. The change of the link status means, for example, that thereceived signal strength of the current link is weak. Of course, achange in the link status could indicate deterioration of otherparameters. Accordingly, the MN 200, particularly, the MIH function unit320 requests information on the surrounding networks in order to preparefor a handover from the current serving network 401 to another network.The MIH function unit 320 requests the MIIS 402 for the surroundingnetwork information using the MIH information service. In this manner,the MN 200 determines the surrounding network information such asreceived signal strengths and attempts a handover to one of thesurrounding networks having an optimal condition for providing servicesto the MN 200. In this example, the MN 200 transmits accurateinformation on its location to the MIIS 401 through the surroundingnetwork information request message.

The MN 200, particularly, the MIH function unit 320 generates its ownlocation information and routing information in step S412 and transmitsMIH_Get_Information.request containing the location and routinginformation to the MIIS 402 in step S415. TheMIH_Get_Information.request message is formatted as follows and theparameters of the MIH_Get_Information.request message are as in table 2.

MIH_Get_Information.request (             InfoQueryType,            InfoQueryParameters,             MIH_LOCATION_REPORT,            MIH_ROUTE_REPORT             )

TABLE 2 Valid Name Type Range Description InfoQueryType An integer valueN/A The type of query corresponding to one of that is specified thefollowing types: 1: TLV 2: RDF_DATA 3: RDF_SCHEMA_URL 4: RDF_SCHEMAInfoQueryParameters Query type specific N/A Query type specificparameters parameters which indicate the type of information the clientmay be interested in. MIH_LOCATION_REPORT String N/A Specifies thelocation information of Mobile Node MIH_ROUTE_REPORT String N/ASpecifies the routing information of Mobile Node in future

In another exemplary embodiment of the present invention, theMIH_Get_Information.request is formatted as follow and the parameters ofthe MIH_Get_Information.request are defined as in table 3.

MIH_Get_Information.request (             DestinationIdentifier,            InfoQueryBinaryDataList,             InfoQueryRDFDataList,            InfoQueryRDFSchemaURL,             InfoQueryRDFSchemaList,            MaxResponseSize,             MIH_LOCATION_REPORT,            MIH_ROUTE_REPORT             )

TABLE 3 Name Type Description Destination MIF_ID The local MIHF or aremote Identifier MIHF which will be the destination of this request.Info Query LIST(INFO_QUERY_BINARY_DATA) (Optional)A list of binaryBinary Data List queries. The order of the queries in the listidentifies the priority of the query. The first query has the highestpriority to be processed by MIIS. Info Query RDFLIST(INFO_QUERY_RDF_DATA) (Optional)A list of RDF queries. Data List Theorder of the queries in the list identifies the priority of the query.The first query has the highest priority to be processed by MIIS. InfoQuery RDF NULL (Optional)An RDF Schema URL Schema URL query. Info QueryRDF LIST(INFO_QUERY_RDF_SCHEMA) (Optional)A list of RDF schema SchemaList queries. The order of the queries in the list identifies thepriority of the query. The first query has the highest priority to beprocessed by MIIS. Max Response UNSIGNED_INT(2) (Optional)This fieldspecifies the Size maximum size of Info Response parameters (i.e., InfoResponse Binary Data List, Info Response RDF Data List, Info ResponseRDF Schema URL and Info Response RDF Schema List) in MIH_Get_Informationresponse message in octets. If this field is not specified, the maximumsize is set to 65,535. The actual maximum size forced by the IS servermay be smaller than that specified by the IS client. MIH_LOCATION_REPORTString Specifies the location information of Mobile NodeMIH_ROUTE_REPORT String Specifies the routing information of Mobile Nodein future

The MIH_Get_Information.request message is transmitted by MN 200 forrequesting information related to specific information, attributes ofthe network interface as well as entire network capability.

As shown in tables 2 and 3, an exemplary handover method uses a newMIH_Get_Information.request message format which additionally includesparameters indicating location information and predicted routinginformation of the MN 200. This location and routing information isgenerated by a location information generator (not shown in drawings) instep S412. The location information generator estimates the location ofthe MN 200 using a Location-Based Service (LBS). The parameterMIH_LOCATION_REPORT indicates the current location of the MN 200 whichis formatted as coordinate information such as latitude and longitudecoordinates used in a Global Positioning System (GPS). The format of thelocation information should be defined in common with the MIIS 402.Since the location information of the MN 200 is transmitted to the corenetwork, the MIIS 402 obtains an accurate location of the MN 200 withoutquerying or estimating the location of the MN 200. Accordingly, the MIIS402 can evaluate the surrounding networks more accurately, whereby thecore network can prepare a handover procedure in advance and, in turn,minimize the handover latency.

The parameter MIH_ROUTE_REPORT indicates a routing path of the MN 200predicted from the current location. For example, in a case where the MNis enabled by GPS, the MN 200 can predict its routing path with thesupport of GPS. When the MN 200 moves along the routing path configuredby a navigator, the MN 200 adds the MIH_ROUTE_REPORT parameter to thenetwork information request message to be transmitted to the MIIS 402.The format of the routing information also should be defined in commonwith the MIIS 402. By providing such routing information to the MIIS402, the MIIS 402 can quickly determine and provide information on thesurrounding networks. Accordingly, the MIIS 402 can predict and schedulethe handovers of the MN 200 using the routing information, therebyimproving handover efficiency and communication stability especiallybetween the heterogeneous networks.

The respective integer values of parameter InfoQueryType correspond toTLV, RDF_DATA, RDF_SCHEMA_URL, and RDF_SCHEMA. When the InfoQueryType isspecified as TLV, the InfoQueryParameters is a binary string containingencoded information element TLVs. When the InfoQueryType is specified asRDF_DATA, the InfoQueryParameters is a string which contains a SPARQL(Protocol and RDF Query language) query where the SPARQL query issupposed to contain an appropriate query for obtaining expected RDF/XMLdata. When the InfoQueryType is specified as RDF_SCHEMA_URL, theInfoQueryParameters is a null string. Finally, when InfoQueryType isspecified as RDF_SCHEMA, the InfoQueryParameters carries either the URLof the extended schema the query originator wants to obtain or a nullstring when the URL of the extended schema is unknown.

In table 3, DestinationIdentifier indicates a local MIH function (MIHF)or a remote MIHF which will be the destination of this request.InforQueryBinaryDataList is an optional parameter indicating a list ofbinary queries. The order of queries in the list identifies the priorityof the query. The first query has the highest priority to be processedby MIIS 402. Also, InfoQueryRDFDataList is an optional parameterindicating a list of RDF queries. Like the InfoQueryBinaryDataList, theorder of the queries in the list identifies the priority of the query.The first query has the highest priority to be processed by the MIIS402. InfoQueryRDFSchemaURL is another optional parameter indicating anRDF Schema URL query. Also, InfoQueryRDFSchemaList is an optionalparameter indicating a list of RDF schema queries. The order of thequeries in the list identifies the priority of the query. The firstquery has the highest priority to be processed by MIIS 402.MaxResponseSize is an optional parameter. This parameter specifies themaximum size of Info Response parameters, i.e., Info Response BinaryData List, Info Response RDF Data List, Info Response RDF Schema URL,and Info Response RDF Schema List in MIH_Get_Information.responsemessage in octets. If this field is not specified, the maximum size isset to 65,535. The actual maximum size forced by the IS server may bysmaller than that specified by the IS client.

Upon receiving the network information request message(MIH_Get_Information.request), the MIIS 402 searches for the surroundingnetworks on the basis of the current location and routing information ofthe MN 200 and determines candidate networks in step S416. At this time,one or more candidate networks can be selected. In the case that therouting information is used, the MIIS 402 can select the candidatenetworks that can provide the optimal quality of service (QoS) along thetravel route of the MN 200. Accordingly, one or more networks can beselected as the candidate networks. For simplifying the presentexplanation, one surrounding network, i.e. the WMAN 403, will beselected as the candidate network using the current location informationin FIGS. 4A and 4B. However, more than one surrounding network can beselected as the candidate networks.

After determining the candidate network, the MIIS 402 transmits aresponse message (MIH_Get_Information.response) containing the candidatenetwork information to the MN 200 in response to theMIH_Get_Information.request in step S417. In a case that theMIH_Get_Information.request received from the MN 200 contains theexpected routing information, if the candidate network informationchanges, for example due to a change in network status, the MIIS 402 maytransmit information of another candidate network to the MN 200 ortransmit information of the changed condition. This message can beprovided to the MIH event service 322. If the changed candidate networkinformation is received, the MN 200 performs a handover to the changedcandidate network.

If the MIH_Get_Information.response is received, the MN 200 determineslink relief information in step 420. In more detail, the link layerentity of the 802.11 interface 312 of the MN 200 notifies the MIHfunction unit 320 that the current 802.11 link is to be released in apreset time. Next, the MIH function unit 320 of the MN 200 reports thelink relief to the MIH user unit 330. In response to a link scanrequest, the 802.16 interface 314 of the interface unit 310 is activatedso as to receive network access information broadcast by the 802.16 WMAN403 in steps S425. Since the candidate network is an 802.16 based WiBronetwork in this example, the network access information is broadcast bythe candidate network. However, the candidate network is not limited tothe WiBro network. The network access information broadcast by the WiBronetwork includes UL MAP, DL MAP, DCD, and UCD. The network accessinformation includes information on the initial ranging performed forsynchronization between the RAS and MN 200, and it is broadcasted by theRAS periodically.

The network access information received through the 802.16 interface 314is transferred to the MIH user unit (or upper layer unit) 330. In thismanner, the MN 200 performs the link scan process in step S430.

After completing the link scan, the MN 200, particularly the MIHfunction unit 320, transmits a candidate query request message(Candidate_Query.request) to the serving network 401 for initiating thehandover in step 432. The Candidate_Query.request includes a link typeidentifier, candidate network identifiers, and information aboutoperations required for the current link after handover. Upon receivingthe Candidate_Query.request message, the serving network 401 transmits ahandover (HO) query resource request message (Query_Resource.request) tothe candidate network 403 in step S435. Since it is assumed that theWLAN 403 is the only candidate network, the serving network 401transmits the Query_Resource.request to the WMAN 403. As describedabove, the candidate network 403 is the best network selected on thebasis of the location information provided by the MN 200.

In response to the Query_Resource.request, the candidate network 403transmits a query resource response message (Query_Resource.response)containing radio resource information to the serving network 401 in stepS437. Upon receiving the Query_Resource.response, the serving network401 transmits a Candidate_Query.response to the MN 200 in step S440.

Once the candidate network is determined, the MN 200 performs anoperation for connecting to the handover candidate network 403 in stepS445. In this example, since the handover candidate network 403 is aWiBro network, the MN 200 performs a ranging process for establishing aconnection link with the candidate network 403.

After completing the ranging process, the 802.16 interface 314 of theinterface unit 310 of the MN 200 notifies the MIH function unit of thehandover completion and then the MIH function unit 320 notifies the MIHuser unit 330 that the link switching is successfully completed in stepS447. In this manner, the MN 200 completes the handover from the WLAN401 to WMAN 403 (the WiBro network). Accordingly, the MN 200 can beserved by the WLAN 401, from the WiBro network continuously in stepS450. Since the MN 200 is connected to the new network 403, the old linkestablished by the 801.11 interface 312 is released according the reliefrequest of the MIH function unit 320.

Although exemplary embodiments of the present invention have beendescribed in detail hereinabove, it should be clearly understood thatmany variations and/or modifications of the basic inventive conceptsherein taught which may appear to those skilled in the present art willstill fall within the spirit and scope of the present invention, asdefined in the appended claims and the like.

1. A handover method in a heterogeneous network environment, the methodcomprising: generating, at a mobile node, self-location information;transmitting the self-location information to a management server whichmanages heterogeneous networks; searching, by the management server,surrounding networks using the self-location information; composing aset of candidate networks including at least one of the surroundingnetworks; transmitting information on the set of candidate networks tomobile node; and deciding, by the mobile node, a target handover networkfrom among the candidate networks.
 2. The handover method of claim 1,wherein the transmitting of the self-location information comprisestransmitting a surrounding network information request message of amedia independent handover function.
 3. The handover method of claim 1,wherein the management server comprises a media independent handoverinformation server.
 4. The handover method of claim 1, furthercomprising obtaining the self-location information using at least one ofa Location-Based Service (LBS) and a Global Positioning System (GPS). 5.A heterogeneous network handover method comprising: generating, at amobile node having multiple standard interfaces, self-locationinformation and self-travel route prediction information; transmittingthe self-location information and self-travel route predictioninformation to a management server which manages heterogeneous networks;searching, by the management server, surrounding networks using theself-location information and self-travel route prediction information;selecting handover candidate networks from among the surroundingnetworks searched along a travel route extracted from the self-travelroute prediction information; transmitting information on the candidatenetworks to the mobile node; and performing, at the mobile node, ahandover to one of the candidate networks.
 6. The heterogeneous networkhandover method of claim 5, wherein the transmitting of theself-location information and self-travel route prediction informationcomprises transmitting a surrounding network information request messageof media independent handover function, and further wherein thetransmitting of the information of the candidate networks comprisestransmitting a surrounding network information response message of amedia independent handover function.
 7. The heterogeneous networkhandover method of claim 5, wherein the management server comprises amedia independent handover information server.
 8. The heterogeneousnetwork handover method of claim 5, wherein the generating of theself-location information and the self-travel route predictioninformation comprises using at least one of a Location-Based Service(LBS), a Global Positioning System (GPS) and a navigator.
 9. Theheterogeneous network handover method of claim 5, wherein thetransmitting of the information on the candidate networks comprises:monitoring to detect status changes of the candidate networks; andtransmitting, if a status change is detected, a changed surroundingnetwork information response containing changed information of thecandidate networks.
 10. A heterogeneous network handover systemcomprising: at least one mobile node for communicating with multipleheterogeneous networks, for generating self-location information, fortransmitting the self-location information to a core network, and forperforming a handover on the basis of candidate network informationreceived from the core network; and a management server for managing theheterogeneous networks, for searching surrounding networks using theself-location information received from the mobile node, for selecting aset of handover candidate networks including at least one of thesurrounding networks, and for transmitting information on the candidatenetworks to the mobile node.
 11. The heterogeneous network handoversystem of claim 10, wherein the self-location information is transmittedusing a surrounding network information request message of a mediaindependent handover function.
 12. The heterogeneous network handoversystem of claim 10, wherein the management server comprises a mediaindependent handover information server.
 13. The heterogeneous networkhandover system of claim 10, wherein the self-location information isgenerated using at least one of a Location-Based Service (LBS) and aGlobal Positioning System (GPS).
 14. The heterogeneous network handoversystem of claim 11, wherein the surrounding network information requestmessage comprises self-travel route prediction information, and asurrounding network information response message comprises informationon candidate networks selected along the travel route of the mobile nodecorresponding to the self-travel route prediction information.
 15. Theheterogeneous network handover system of claim 10, wherein themanagement server monitors to detect status changes of the candidatenetworks and transmits, if a status change is detected, a changedsurrounding network information response containing changed informationof the candidate networks.
 16. A heterogeneous network handoverapparatus comprising: a plurality of radio interfaces for communicatingwith heterogeneous networks; a self-location information generator forgenerating self-location information and self-travel route predictioninformation; and a media independent handover function unit fortransmitting a surrounding network information request messagecontaining the self-location information and the self-travel routeprediction information to a heterogeneous network management server andfor receiving a reply message in response to the surrounding networkinformation request message.
 17. The heterogeneous network handoverapparatus of claim 16, wherein the plurality of radio interfacescomprises: an Institute of Electrical and Electronic Engineers (IEEE)802.11 interface; an IEEE 802.16 interface; and a cellular interface.18. The heterogeneous network handover apparatus of claim 16, whereinthe self-location information is generated using at least one of aLocation-Based Service (LBS), a Global Positioning System (GPS) and anavigator.
 19. The heterogeneous network handover apparatus of claim 16,wherein the media independent handover function unit comprises: an eventservice module: a command service module; and an information servicemodule.
 20. The heterogeneous network handover apparatus of claim 16,wherein the media independent handover function unit initiates ahandover using information in the reply message.